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Abstract. In this paper we use the Epigram language to define the 
universe of regular tree types — closed under empty, unit, sum, product 
and least fixpoint. We then present a generic decision procedure for Epi- 
gram's in-built equality at each type, taking a complementary approach 
to that of Benke, Dybjer and Jansson [7]. We also give a generic defini- 
tion of map, taking our inspiration from Jansson and Jeuring [21]. Fi- 
nally, we equip the regular universe with the partial derivative which can 
be interpreted functionally as Huet's notion of 'zipper', as suggested by 
McBride in [26] and implemented (without the fixpoint case) in Generic 
Haskell by Hinze, Jeuring and Loh [18]. We aim to show through these 
examples that generic programming can be ordinary programming in a 
dependently typed language. 

1 Introduction 

This paper is about generic programming [6] in the dependently typed func- 
tional language Epigram [28,29]. Generic programming allows programmers to 
explain how a single algorithm can be instantiated for a variety of datatypes, 
by computation over each datatype's structure. In particular, we construct the 
universe of regular tree types — the datatypes closed under empty, unit, sum, 
product and least fixpoint. We define a de Bruijn indexed syntax [14] for these 
types, but we do not interpret this syntax via a recursive function: rather we give 
the elements for a given type as an inductive family [16]. It is Epigram's support 
for dependent pattern matching [13] which makes this approach practicable. 

The universe of regular tree types is small compared to others we might 
imagine [4, 7], but it is rich in structure. We exploit some of that structure in our 
programs: Epigram's standard equality is decidable for every regular tree type; 
every regular tree type constructor has a notion of functorial 'map'; we also give 
the formal derivative of each type expression, including fixpoints, and acquire the 
related notion of one-hole context or 'zipper' [20]. In the last example McBride's 
observation [26], given its explanation in [3], has finally become a program. 

1.1 What is a universe? 

The notion of a universe in Type Theory was introduced by Per Martin-L6f [25, 
33] as a means to abstract over specific collections of types. A universe is given 
by a type U : * of codes representing just the types in the collection, and a 



function T : U — > * which interprets each code as a type. A standard example 
is a universe of finite types — each type may be coded by a natural number 
representing its size. We can declare the natural numbers in Epigram as follows 



data 



Nat 



where 



Nat 



zero : Nat sue n : Nat 



One way to interpret each Nat as a finite type is to write a recursive function 
which calculates a type of the right size, given an empty type Zero, a unit type 
One and disjoint unions S + T 



let 



Nat 



fin n 



fin n <= rec n 
fin zero => Zero 
fin (sue n) =>■ One + fin n 



Another way is to define directly an inductive family [16] of finite types: 



data 



Nat 



Fin n : * 



where 



Fin n 



fz : Fin (sue n) f s i : Fin (sue n) 



Fin n gives a coding of the set {0, . . . , n — 1}. Fin zero is uninhabited because no 
constructor targets it; Fin (sue n) has one more element than Fin n. Below we 
tabulate the first few types in this family: we show the 'n' arguments to fz and 
fs — usually left implicit — as subscripts, and write in decimal to save space. 



Fin 0 



Fin 1 



Fin 2 Fin 3 



fzi fz 2 
fsi fzo fS2 fzi 

fs 2 (fsi fz 0 ) 



Fin 4 



fz 3 

fs 3 fz 2 

fs 3 (fs 2 fzi) 

fs 3 (fs 2 (fsi fz 0 )) 



In either presentation, Nat acts as a syntax for the finite types which we then 
equip with a semantics via fin or Fin. Let us emphasize that Nat is an ordinary 
datatype, and hence operations such as plus can be used to equip the finite 
universe with structure: Fin (plus m n) is isomorphic to Fin m + Fin n. Universe 
constructions express generic programming for collections of datatypes [6, 18, 21] 
in terms of ordinary programming with their codes. 

The notion of universe brings an extra degree of freedom and of precision to 
the business of generic programming. By their nature compiler extensions such 
as Generic Haskell [10] support the extension of generic operations to the whole 
of Haskell's type system, but we are free to construct a continuum, from large 
universes which support basic functionality to small, highly structured universes 
which support highly advanced functionality. Benke, Dybjer and Jansson provide 
a good introduction to this continuum in [7]. In fact every family of types, 
whether inductive like Fin or computational like fin, yields a universe. 



1.2 From Finite Types to Regular Tree Types 



The finite types are closed under 'arithmetic' type constructors such as empty, 
unit, sum and product. If we also add list formation, we leave the finite universe 
and acquire the regular expression types. We can code these (with respect to an 
alphabet of size n) by the following syntax 

data " : Nat where i : Fin n 



Rex n : * fail, nil, dot : Rex n only i : Rex n 

S, T : Rex n R : Rex n 

S or T, S then T : Rex n R star : Rex n 

So for instance we translate the regular expression 

(A + BC)* C {A,B,C}* 

into the code 

((only fz) or ((only (fs fz)) then (only (fs (fs fz))))) star : Rex 3 

From each regular expression in the syntax, we may then compute a type which 
represents the words which match it. 

let K \ Re * w Words n R <= rec R 
— Words n R : * n — 

Words„ fail Zero 

Words n nil =>• One 

Words n dot ^> Fin n 

Words n (only i) ^> Single i 

Words n (S or T) => Words„ 5" + Words„ T 

Words n (5 then T) => Words„ S x Words„ T 

Words„ (R star) =4> List (Words„ R) 

Some example Words of the expression above would be represented thus: 

BCA i— > [inr (single (fs fz); single (fs (fs fz)), inl(single fz)] 
A i— > [inl (single fz)] 

This universe, like the finite types, has much algebraic structure to expose, 
and there is plenty of ad hoc work devoted to it, motivated by applications to 
document structure [19]. 

Moving just a little further, we can generalise from lists to trees by replacing 
star with a binding operator fi which indicates the least fixpoint of an algebraic 
type expression. Closing under gives us the universe of regular tree types. In 
effect, we acquire the first-order fragment of the datatypes found in Standard 
ML [31]. These include the string-like structures such as the natural numbers, 
fiN. 1 + N and the lists of A's, [iL. 1 + A x L, but also branching structures 
such as binary trees \iT. 1 + TxT. Nesting \i yields structures like the finitely 



branching trees, whose nodes carry lists of subtrees, \iF. /iL. 1 + F x L. It is this 
class of types together with the structures and algorithms they support, which 
we shall study in this paper. 

Of course, there are plenty more universes to visit. Altenkirch and McBride 
construct the nested datatypes, allowing non-uniform type constructors to be de- 
fined by recursion [4]. Bcnke, Dybjer and Jansson construct the indexed induc- 
tive definitions [7, 17], their motivation being that these structures are effectively 
those of the Agda system [12] with which they work. 

1.3 Programming in Epigram 

Epigram [28, 29] is a functional programming language with an interactive editor, 
incrementally typechecking source code containing sheds, [ • • • ] , whose contents 
are free text which remains unchecked. It supports programming with inductive 
families in a pattern matching style, as proposed by Thierry Coquand [13] and 
first implemented in the Alf system [24] . 

However, Epigram programs elaborate into a version of Luo's UTT [22]. This 
is a more spartan and more clearly defined theory than that of Alf, equipping 
inductive families only with the induction principles which directly reflect their 
constructors. In this respect, Epigram more closely resembles its direct ancestor, 
Lego [23], and also to some extent the Coq system [11]. The design criteria for 
a good high-level programming language and a good low-level core often pull 
in opposite directions, hence we separate them. At present, neither Agda nor 
Coq directly supports pattern matching with inductive familes hand-coding 
our constructions in these systems would be possible but unnecessarily painful. 

Epigram's data structures are introduced by declaring their applied formation 
rules and constructors in a natural deduction style. Argument declarations may 
be omitted where inferrable by unification from their usage — for example, in 
our declarations of Fin's constructors, fz and fs, there is no need to declare 
n : Nat. The resemblance between constructor declarations and typing rules is 
no accident. We intend to encourage the view of an inductive family as a universe 
capturing a small type system — and that is exactly how we work in this paper. 

Epigram functions are given a type signature, also in the natural deduction 
style, then developed in a decision tree structure, shown here by indentation 
and representing a hierarchical analysis of the task it performs. Each node in 
a decision tree has a left-hand side which shows the information available, in 
the form of the patterns into which the arguments have been analysed, and a 
right-hand side which explains how to proceed in that case. The latter may take 
one of three forms: 

=>■ t the function returns t, an expression of the appropriate type, con- 
structed over the pattern variables on the left; 

<= e the function's analysis is refined by e, an eliminator expression, charac- 
terising some scheme of case analysis or recursion, giving rise to a bunch of 
subnodes with more informative left-hand sides; 



I w the subnodes' left-hand sides are then extended with the value of w, some 
intermediate computation, in an extra column: this may then be analysed 
in addition to the function's original arguments. 



In effect, Epigram gives a programming notation to some constructions which 
are more familiar as tactics in proof systems: => corresponds to Coq's exact and 
| resembles generalize; is McBride's elimination tactic [27]. McBride and 
McKinna give a thorough treatment of Epigram elaboration in [29] , and begin 
to explore the flexibility of the <= construct. In this paper, however, we shall 
need only the standard constructor-guarded recursion operators recx, which we 
make explicit, and the standard constructor case analysis operators case a:, which 
we leave implicit whenever their presence is directly inferable from the resulting 
constructor patterns. In general, we are only explicit about case analysis when 
its results are empty: 

let -. : .f i n zero -, — impossible x case x 

— impossible x : Zero 

Case analyses in Epigram, as in Alf, are constrained by the requirement in 
each branch that the indices of the scrutinee — zero for x : Fin zero above — 
coincide with those of the constructor pattern in question — above, (sue n) in 
both cases. When they concern constructor symbols, these constraints are auto- 
matically simplified by first-order unification: impossible cases are dismissed, as 
above, and the possible cases arc simplified. The ^= construct thus generalises 
Alf's dependent constructor matching 'in software'. 

Before we start work in earnest, we must own up to the notational liberties 
we have taken in this paper which the current implementation of Epigram does 
not support. At present, neither the | w notation, nor the suppression of obvi- 
ous case . . . nodes has been implemented: both omissions have simple but 
verbose workarounds — expanding the programs here would shed more heat than 
light. More trivially, we work in ASCII rather than MTj^X and have only prefix 
operators thus far — the notation we use here is cosmetically more advanced. 

2 The Universe of Regular Tree Types 

We define the codes for the regular tree types as follows: 

data 



n : Nat 



Reg n : ★ 

wW T : Reg n S : Reg n T : Reg (sue n) 

'Z' : Reg (sue n) 'wk' T : Reg (sue n) 'let' S T : Reg n 

S, T : Reg n F : Reg (sue n) 



£ 0',T : Reg n 5'+' T, S'x' T : Reg n 'fx' F : Reg n 

This is syntax-with-binding in de Bruijn style — the numeric index gives the 
number of free type variables available in the expression. The 'Z' refers to the 



most local variable (de Bruijn index zero), where there is one; the weakening 
constructor 'wk' , read backwards, discards the top variable, allowing access to 
the others. We can thus define an embedding from Fin n to the representation 
of variables in Reg n 

let ; ^i, Fin D n 'var' X rec X 

— 'var X : Reg n . . , — ._, 
'var fz => 'Z' 

'var' (fs X) =>■ 'wk' ('var' X) 

Both '/i' (least fixpoint) and 'let' (local definition) bind a variable. The latter 
clearly introduces redundancy, as does the applicability of 'wk' to expressions 
other than variables. We could have chosen a redundancy free representation, 
making 'var' a constructor and dropping 'Z', 'wk' and 'let'. Such a syntax could 
be equipped with a renaming functor and a substitution monad as in [5] and we 
should need this equipment and proofs of its properties to do our work. Definition 
and weakening replace just enough of the behavior of substitution for us to avoid 
this extra effort. 

A similar choice presents itself when we come to interpret this syntax. It 
seems natural to interpret only the closed type expressions — the elements of 
Reg zero — substituting whenever we go under a '/i' or 'let' binder. Some simple 
operations, such as our generic equality, become even simpler if we take this 
choice, but other operations, such as 'map', require us to work with properties 
of substitution. We choose to sidestep substitution in the usual way, interpreting 
open expressions over an environment. We construct our environments carefully 
to support the way we shall use them: they are telescopic [15] in the sense that 
each new variable is bound to an expression over the previous variables. 

data n : Nat 

wnere fa : Tel n t : Reg n 

Tel n : * e : Tel zero ts:t : Tel (sue n) 

We can now interpret every type expression without having to rename de Bruijn 
indicies at run time to account for the new context or substituting out to a closed 
expression. Notice that the inductive structure of [— ] _ is not the inductive 
structure of Reg — the size of an element is not bounded by the size of its type. 



data 



r : Tel n T : Reg n 



where 



t 



l F t : ITT t : [T] r!S 

top t : ~fZ'Y"- T pop t : ['wk' def t : ['let' S Tf 

s ■■ isy t : m r 

inl s : IS '+' T] r inr t : [5 '+' T] r 



s : t : [T] r x : jFf r ~-V F ) 

void : ['l'] r pair si : [S*'x'T] r in a; : W F\ r 



The telescopic environments behave as we promised. The rule for 'Z' interprets 
the top type T over the remaining _T — but how did it get there? Either from 



a 'let' or a extending r with a type which is defined over it! The rule for 
'wk' just pops the environment. Most interesting is the definition of in, which 
uses the environment to expand the fixpoint — let us show how this behaves by 
coding the natural numbers: 

k " Naf : Reg, V " =* " C 1 ' Z! 



kt ^r-rwr kt _ ir<i\wn.r 



n : I'Nat'] r 

ze : ['Nat'] r — sun : ['Nat'^ 

ze in (inl void) su n => in (inr (top n)) 

The in constructor places a recursive copy of 'Nat' on top of the telescope, which 
su invokes via top. We can program with 'Nat' quite easily: 

, , m,n : |'Nat'1 r , 

let — — . t1 . T " , r plus m n <= rec m 

plus m n : Nat , ,nn 

1 * plus (in (ml void)) n =>■ n 

plus (in (inr (top m))) n =>■ su (plus m n) 

Note that the patterns on the left correspond to ze and su. These cases are 
exhaustive — all the other constructors target types which conflict with the defini- 
tion of 'Nat', so Epigram dismisses them automatically. The recursive structure 
of the whole [— ]~ family, thus specializes to that of ['Nat'] r . 

Our recognizably inductive presentation contrasts with Benke, Dybjer and 
Jansson's recursive definitions of the functor given by each code in a universe, 
whose least fixpoint is in turn the coded type. Whilst in all of their examples, 
it is clear to us that the computed functors are strictly positive and give rise to 
inductive types, they make no apparent attempt to explain this to Agda. 

The space efficiency of [— ]~ is a serious concern: on the face of it, each data 
constructor takes an environment and perhaps some type expressions as argu- 
ments. Even if sharing is preserved, this is particularly wasteful. Fortunately, as 
Brady has shown [8, 9], there is no need to duplicate in the data any information 
extractable from the type indices, so all of the T's, S's and T's vanish, even 
from the open representation we need for partial evaluation in the typechecker. 

Further, Brady's work suggests that we can also remove constructor tags 
where these are determined by indices. In our case, this means that only elements 
of sums need to be tagged inl or inr, as each of the other type formers has at 
most one data former. Hence there is no need for an extra layer of indirection 
inside each top, pop, def or in. There is no reason why our explicit definition and 
weakening has to lead to a space penalty. 



3 Deciding Equality 

Every regular tree type can be given a decidable equality in a systematic way. 
In this section, we express that system as a program. Equality as a Boolean test 
has been a standard example of generic programming from PolyP onwards [21]. 



Bcnke, Dybjer and Jansson replay this construction in Agda [7] and, moreover, 
they prove generically that what is being tested really behaves like equality, in 
that it is reflexive and substitutive. We take a slightly different approach, given 
that Epigram has a built in equality type [27] which is reflexive by construction, 
and substitutive by case analysis: 

a : A b : B 



refl : a=a 



Rather than proving a Boolean test correct, we can exploit directly the type of 
decisions, which packs up either a proof or a refutation for a given proposition: 

data _ P. ■ * where y - ' P . p n : P r^ Zero p 

Decision P : * yes y : Decision P non : Decision P 

To decide the equality of x and y, and know that we have done so, we must 
show how to compute an inhabitant of Decision (x=y). We can get most of the 
way by analysing each element and inspecting the results of the recursive calls 
on corresponding subterms — see 1. 

Again, dependent pattern matching ensures that we need only consider ele- 
ments which have the same type. Fundamentally, all inequalities boil down to 
the fact that inl and inr are different: inl s = inr t is an empty type, so case anal- 
ysis leaves no branches. We have left [ ] s for most of the cases where we must 
show that recursive inequality of subterms breaks equality for the whole terms. 
Each of these proofs require an auxiliary definition all of which follow the same 
pattern. The proof for in is given below. 

^ x,y : |F] r: ^ F ' n : (x=y) — > Zero q : (in a;=in y) 
— notEqln^ y n q : Zero 

notEqIn x x n refl =>■ n refl 



4 Type Constructors and Generic Map 

We can represent type constructors in our universe by type expressions with 
parameters, much as one does when one defined a polymorphic data structure 
in a functional programming language. For example, we can have 

let j^—. — = — -. v 'List' ^ '[i* ('1"+' ('wk"Z"x"Z')) 

— List : Reg (sue n) 

We can then create specific instances of polymorphic structures by capturing 
the free parameter with 'let' — the type of lists of natural numbers would then 
be coded by 'let' 'Nat' 'List'. We can also develop polymorphic operations by 



let a 'P : ^ 

— decEq x y : Decision (x=y) 



decEq 


X 


y 


<= rec x 






decEq 


(def x) 


(def </) 


1 decEq x y 






decEq 


(def x) 


(def x) 


yes refl 


=> yes 


refl 


decEq 


(def x) 


(def y) 


no n 


=> no 


[] 


decEq 


(top x) 


(top y) 


1 decEq x y 






decEq 


(top x) 


(top x) 


yes refl 


=>■ yes 


refl 


decEq 


(top x) 


(top y) 


no n 


=>■ no 


[] 


decEq 


(pop x) 


(POP 2/) 


1 decEq x y 






decEq 


(pop x) 


(pop x) 


yes refl 


=> yes 


refl 


decEq 


(pop x) 


(pop y) 


no n 


=>■ no 


[] 


decEq 


void 


void 


=>■ yes refl 






decEq 


(inl sx) 


(inl sy) 


decEq sx sy 






decEq 


(inl s) 


(inl s) 


yes refl 


=>■ yes 


refl 


decEq 


(inl sx) 


(inl sy) 


no sn 


=>■ no 


[] 


decEq 


(inl sx) 


(inr fy) 


=>■ no (Ag 


case g) 




decEq 


(inr tx) 


(inl sy) 


=>■ no (Xq ■<= 


case g) 




decEq 


(inr tx) 


(inr ty) 


decEq tx ty 






decEq 


(inr t) 


(inr i) 


yes refl 


=>■ yes 


refl 


decEq 


(inr tx) 


(inr ty) 


no tn 


=>■ no 


[] 


decEq 


(pair sx tx) 


(pair sy ty) 


decEq sx sy 






decEq 


(pair s fa;) 


(pair s ty) 


yes refl 


decEq tx ty 


decEq 


(pair s t) 


(pair s t) 


yes refl 


yes 


refl =>■ yes refl 


decEq (pair s tx) 


(pair s *y) 


yes refl 


no tn => no [ 


decEq 


(pair sx tx) 


(pair sy ty) 


no sn 


=>■ no 


[] 


decEq 


(in x) 


(in J/) 


| decEq x y 






decEq 


(in a:) 


(in x) 


yes refl 


=>■ yes 


refl 


decEq 


(in a;) 


(in y) 


no n 


=>■ no 


(notEqln n) 



Fig. 1. Decidable Equality 



working with open type expressions over a nonempty environment: 



— nil : ['Listf ' nil ^ in (in! void) 

, , a : f'Z'F as : ['List'F Wi 

let - — - rT~r* — -n r cons a as =>■ in (inr (pair (pop a) (top as))) 

cons a as : | List'| J 

let as,bs : ['List'] r 



append as bs : ['List 

append as bs <= rec as 

append (in (inl void)) bs =>■ bs 

append (in (inr (pair (pop a) (top as)))) bs =>■ cons a (append as bs) 



Of course, to apply these polymorphic operations in specific cases, one must strip 
and apply the def constructor. 

Let us now develop a generic polymorphic operation — functorial mapping. 
Suppose we have two environments r and A interpreting the free type variables 
in an expression T ('List', for example). If we can translate between the values 
in the corresponding types in r and A, then we can map between [T] r and 
[ T] A , preserving the structure due to T, but translating the data corresponding 
to the free type variables. Here, the fact that we represent the syntax of type 
expressions makes this task easy. 

Let us define morphisms between environments and then show how to map 
them across polymorphic type expressions. We are careful to ensure that we can 
readily extend a morphism uniformly when we go under a binder. 



1 ,Zi : lei n , 

Morph r A : * mid : Morph T T 

0 : Morph r A f : IS} F -» jTj 
mFun 4>f : Morph (r-.S) (A: T) 

<f> : Morph £ A 

mMap 0 : Morph (T: T) (A:T) 



We can now write our generic gMap operator by structural recursion on data. 
Each time we go under a binder, we extend the morphism with mMap, explaining 
that the type variable at that point is local. When we reach a variable, we look 
up the appropriate translation, using gMap to interpret mMap. In the case of 
the identity morphism, the environments are known to coincide, so no further 
traversal is necessary. 



<j> : Morph r A x : [T] 
gMap 0 a; : {Tj A 



gMap 


4> 




X 


gMap 


4> 




(def x) 


gMap 


mid 




(top x) 


gMap 


(mFun (f) 


f) 


(top x) 


gMap 


(mMap 


0) 


(top x) 


gMap 


mid 




(pop x) 


gMap 


(mFun 6 


/) 


(pop x) 


gMap 


(mMap 




(pop x) 


gMap 


0 




(inl x) 


gMap 


0 




(inr x) 


gMap 


4> 




void 


gMap 


4> 




(pair x y) 


gMap 


4> 




(in x) 



<= rec x 

=> def (gMap (mmap <f) x) 

=> top x 

=> top (/ x) 

=> top (gMap <j> x) 

=> pop x 

^> pop (gMap (j) x) 
=^ pop (gMap (f> x) 

inl (gMap 4> x) 

inr (gMap <\> x) 

void 

=>■ pair (gMap <\> x) (gMap (f> y) 
in (gMap (mMap (f) x) 



Instantiating gMap for our 'List' example is straightforward 



/ : jSj r ^ m F gg : [Met' 5 'List'lT 
— list / as : ['let' T'List'] r 

list / (def as) =>- def (gMap (mFun mid /) as) 

Is this functorial mapping? An easy induction on x shows that 

gMap mid x = x 

but what about composition? Composition may be defined as follows 

, , 4> : Morph A O : ★ ip : Morph r A : * 
— <j)o^ : Morph T O 

(j) o ip -<= rec <f> 

mid o ip =>• ip 
mFun 0/o mid mFun<^>/ 
mFun <p f o mFun ip g mFun ((f) oip) (f ■ g) 

mFun 0/ o mMap ip =>■ mFun (0o ip) (f ■ gMap ?/>) 

mMap0 o mid => rnMap^ 

mMap0 o mFun?/; g =>■ mFun (</>o ^1) (gMap <p ■ g) 
mMap^ omMap^ mMap (</> o ip) 

Another easy induction on x then shows that 

gMap (<poip) x = (gMap <p ■ gMap ip) x 



5 The Derivative and the Zipper 



Formal differentiation of algebraic expressions was one of the first functional 
programs ever to be written in pattern matching style and executed on a com- 
puter [30] . Thirty-five years later we can run it again, but with a new meaning. 
As McBride observed [26] , differentiating a regular tree type T with respect to 
a free variable X computes the type of one-hole contexts for a value from X in 
a value from T. The explanation of the derivative as coding for the linear part 
of a polymorphic function space between containers can be found in [3] . Here we 



show how this works out as code: 



, , X : Fin n T : Reg n 
— d X T : Reg n 

d X T <= rec T 

d fz 'Z' =*> T 

<9(fsX) 'Z' => '0' 

d fz ('wk' T) => '0' 

d(fsX) ('wk' r) ^ 'wk ! (Mr) 

6» X ('let' S* T) ^ 'let' S (d (fsX) T) 

'+' 'let' S (d fz T) 'x ' 9IS 
'0' => '0' 
d X T =>• '0' 
9 X (£'+' r) dXS '+' 91 T 
6> X (S 'x' T) =► dX S 'x' T '+' S'x'SIT 
9 X ('m'F) ^ '/i' (T '+' 'Z"x"wk' ('let' O' F) (5fzF))) 

'x"let' ('/i' F) {d (fsX) F) 

Rules we learned from Leibniz take on a direct visual intuition: 'an 5* '+' T 
with a hole' is either 'an 5 with a hole' or 'a T with a hole'; 'an 5 'x' T with 
a hole' is either 'an S with a hole and a T' or 'an S and a T with a hole'. The 
chain rule for 'let' must account for each fs X directly in T as well as each X 
sitting inside an S via a fz in T — this notion of derivative is thus partial on 
the free variables and total on the bound variables. McBride added a new rule, 
inspired by Huet [20] — a one hole context inside an inductively defined container 
consists of a 'zipper' which wraps up the node where the hole is. Let us define a 
'zipper': 

let F : Reg (sue n) 
— 'Zipper' F : Reg n 

Zipper' F => y (T '+' 'Z"x"wk' ('let' f>' F) (<9fzF))) 

A 'Zipper' F is thus a stack of steps, each giving the context for a 'Z' inside an 
F, and hence a recursive subtree inside a '/i'F. With this definition, we effectively 
have that d X ('/x' F) is a node with a hole and a 'Zipper' F. 

Notice that it is our access to the full syntax of type expressions which enables 
us to differentiate types with multiple parameters, and hence local definitions 
and fixpoints. By contrast, programmers in Generic Haskell have no access to 
these syntactic details. Often this is a convenience, but here it restricts the 
treatment given by Hinze, Jeuring and Loh [18] to polynomials in one variable. 

Let us now show how to plug a 'var' X into a d X T, and a '/i' F into a 
'Zipper' F. It is not hard to see that these two tasks are mutually recursive. 
We shall therefore need to dodge the problem that Epigram does not currently 
support mutually recursive functions. We do this in the obvious way, by turning 
the mutual definition into the definition of a family. First, we define the family 



of 'pluggers' for a type of contexts C with a hole type H , yielding output in O, 

d C, H, O : Reg n , X : Fin n T : Reg n 

Plugger C H O : * X ^ T : Plugger (9 X T) ('var' X) T 

F : Reg (sue n) 
O F : Plugger ('Zipper' F) (y F) ('/i' F) 

and then we explain how to interpret pluggers as operators, by recursion over 
the context — as long as we consume the context, we are free to 'change mode' 
when we need to. We start like this, by recursion on the task, then case analysis 
on the plugger: 



p : Plugger C H O c : [C] r ft : pFj J 

~ u \i 

c (X ^> T] ft 



let f ■ ' m e>S c ' ^ " ^ ■ IL^JI ■ r (n\ h 4= rec r 

— c{p]h:[OJ r — 



c(OF]ft [] 

Now we can develop the two branches as if we were writing a mutual definition. 
We implement (X — o T] as follows: 

void (fz^'Z'] h => h 

c (fsX— o'Z'] ft case c 

c (fz — o 'wk' T] ft -4= case c 

pop c (fsX -o 'wk' T] pop ft pop (c (X -o T] ft) 

inl (def fc) (X — o 'let' S T] ft =>• def (tc (fs X —o T] pop ft) 

inr (pair (def tc) sc) (X -o 'let' S T] h def (ic (fz -o T] 

top (sc (X -o 5] ft)) 



c 



(X -o 'O'l ft 4= case c 



c (X — o '1'] ft <= case c 

inl sc (X^>S*'+'T] ft => inl (sc (X -° 5*] ft) 

inr ic (X — o 5 '+' T] ft inr (ic (X -o T] ft) 

inl (pair set) (X^S'x'T] ft =*> pair (sc (X -o S] ft) t 

inr (pair sic) (X-oS'x'T] ft pair s (tc (X —° T] ft) 

pair ff (def fc) (X -o < M ' F] ft (O F] 

in (/c (fs X -o F] pop ft) 

Meanwhile, 'zipping out' iterates 'plugging in' tail recursively: 

in (inl void) (OF] ft =>• ft 

in (inr (pair (top#) (pop (def /c)))) (OF] h ff (0 F] 

in (/c ('Z'-oF] top ft) 

This may look like a complicated definition, but we had some help to write it. 
The Epigram system calculates all the context types, not us: we just apply case 
analysis repeatedly on the contexts until the subcontexts appear. The only real 
choice we must make is whether (O F] should read its context as 'hole-to-root' or 
'root-to-hole'. Here, following Huet, we choose the former, shrinking the context 
and growing the subtree as we follow the path. 



6 Conclusions and Further Work 



In this paper, we have constructed the universe of regular tree types, closed un- 
der polynomials and least fixpoints; we equipped its syntax with an inductively 
defined semantics. By dependent pattern matching and structural recursion on 
data, we implemented a generic decision procedure for equalities on regular types 
and functorial mapping. We equipped the regular tree types with their differ- 
ential structure, generalising 'the zipper'. We have given a tractable coding to 
these generic tasks without the assistance of any peculiar extensions to Epigram. 
Ordinary programming suffices to get us this far, and while it is inevitably harder 
work than using tools dedicated to a specific universe, it is undeniably less work 
than making those tools. A dependently typed language allows a flexible ap- 
proach to programming with universes of many characters, large and small. 

Perhaps we should remark on the technology which makes this approach 
practicable — dependent pattern matching with inductive families of datatypes. 
We have quietly exploited multiple layers of dependency, with equality types 
indexed by data from interpretations indexed by telescopes and type expressions 
indexed by numbers, for example, and we have not had to lift a finger to push the 
pattern matching through. This kind of deep dependency takes us well beyond 
the familiar world of inductive relations indexed by simply typed data, but it is 
nothing to be frightened of, given suitable tools. 

There is a great deal of work yet to do. Whilst we have programmed generi- 
cally in a small and ad hoc universe, we have not developed generic programming 
for Epigram. We should pursue the agenda set by Pfeifer and Ruefi [32] to acquire 
generic programs and proofs for the types we use, not just those we model. 

This is even more vital for dependently typed programming than it is for 
'ordinary' functional programming because we tend to tailor data structures 
more closely to the specific properties we need for a given task. We might have 
sized lists, sorted lists, telescopes or transitive closures where once we just had 
lists the extra detail may be just what we need for a particular problem, but it 
should not come at the expense of rebuilding the list library for each variation. 
Generic programming can potentially help us in two ways. We can seek to develop 
operations which work generically for all list-like types, or all concrete syntaxes, 
or whatever classes of structure we can characterise. We can also seek to roll out 
structure such as sizing or sortedness across a broad universe of datatypes. 

Correspondingly, we need a representation of data structures which directly 
and compositionally describes inductive families in Epigram, in much the way 
that indexed induction-recursion [17] gives an account of data structures in Agda. 
A promising approach is based on the uniform representation of strictly positive 
structures as containers [1,2]. These extend readily to dependent structures, and 
are closed under a fixed grammar of combinators including least and greatest 
fixpoints. We need the system to automate the quotation of data structures in 
this grammar and the maps in and out of their container form — much the way 
Generic Haskell [10] relates each Haskell datatype with the 'structure types' 
over which generic programs actually compute. Subsets of this general grammar 
then give us codes for smaller universes with more specific structure. If we can 



standardise our reflection of data structures in this way, then we really shall have 
reduced generic programming to ordinary programming. 
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